can I suggest a modification, where has public and does not have relayed, as frequently due to this issue devices have both, e.g. 4.1k validators have a public IP, and 2.5k of them also have a relayed address right now.

I don't think it will matter since if it has a public ip address that will be the prioritized address that you connect to. That it also has a p2p address does not indicate that the peer itself has a broken internet configuration, just that it was hit by the same problem this commit tries to prevent.

I will run a second node with your suggestion and see if it makes any difference regardless 👍

thanks, and also for the additional insight!

The instance with this check has been running over the weekend without starting up a relay so this fix seems to prevent (at least a large part) of the issue. The second instance that also prevents selecting connected peers with a p2p address (as secondary address) achieved the same results so I propose to keep the change minimal and only check for a public IP.

Removing the draft label as the fix has had the intended result over a longer run.

confirming no issues in running, appears to resolve or at least help issue.

confirming still no issues, some weeks later

This is actually wrong as libp2p_peer:connected_peers() doesn't return peerbook entries itself, but rather pubkey bins, which are not valid to call libp2p_peer:listen_addrs() on.